---
title: Certificate Transparency (CT) Logs
slug: ct-logs
lastmod: 2025-08-27
show_lastmod: 1
---

<p>
  <a href="https://www.certificate-transparency.org/what-is-ct"
    >Certificate Transparency (CT)</a
  >
  is a system for logging and monitoring the issuance of TLS certificates. CT
  greatly enhances everyone's ability to monitor and study certificate issuance,
  and these capabilities have led to numerous improvements to the CA ecosystem
  and Web security. As a result, CT is rapidly becoming critical infrastructure.
</p>

<p>
  Let's Encrypt submits all certificates we issue to CT logs. We also operate CT logs.
  All publicly trusted certificate authorities are welcome to
  submit to our logs. Many certificate authority root certificates have already
  been included in our CT logs. If you operate a Certificate Authority and your issuer
  is not in our accepted issuers list, please file an issue <a href="https://github.com/letsencrypt/ct-log-metadata">here</a>.
</p>

<p>
  Sign up for notifications in the
  <a
    href="https://community.letsencrypt.org/t/about-the-ct-announcements-category"
    >CT announcements category</a
  >
  of our community forum to see major announcements about our CT logs.
</p>

<h2>Funding</h2>

<p>
  If your organization would like to help us continue this work,
  please consider
  <a href="https://www.abetterinternet.org/sponsor/">sponsoring or donating</a>.
</p>

<h2>Architecture</h2>

<p>
  Check out our blog to see
  <a href="https://letsencrypt.org/2019/11/20/how-le-runs-ct-logs.html"
    >How Let's Encrypt Runs CT Logs</a
  >!
</p>

<h2>Log Monitoring</h2>

<p>
  Let's Encrypt has created an open-source CT log monitoring tool called
  <a href="https://github.com/letsencrypt/ct-woodpecker">CT Woodpecker</a>. We
  use this tool to monitor the stability and compliance of our own logs, and we
  hope others will find it to be useful as well.
</p>

<h2>CT Logs</h2>
<p>
Information about the various lifecycle states that a CT log progresses through can be found <a href="https://googlechrome.github.io/CertificateTransparency/log_states.html">here</a>.
</p>

<h3>Sunlight</h3>
<p>
  Let's Encrypt is transitioning to operating logs based on <a href="https://sunlight.dev">Sunlight</a>.
  Information including accepted roots, public keys, log IDs, and shard intervals are available at each log's
  landing page, linked below.
</p>
<p>Sycamore and Willow are our new production CT logs, accepting certificates from trusted CAs.</p>
<ul>
  <li><b>Sycamore</b>: <a href="https://log.sycamore.ct.letsencrypt.org/">log.sycamore.ct.letsencrypt.org</a></li>
  <li><b>Willow</b>: <a href="https://log.willow.ct.letsencrypt.org/">log.willow.ct.letsencrypt.org</a></li>
</ul>
<p>Twig is a test log, accepting certificates from trusted CAs as well as some additional test CAs, including the Let's
  Encrypt staging environment.</p>
<ul>
  <li><b>Twig</b>: <a href="https://log.twig.ct.letsencrypt.org/">log.twig.ct.letsencrypt.org</a></li>
</ul>


{{< ct_logs data="production" >}}
<li>
  Oak is incorporated into the
  <a href="https://support.apple.com/en-us/HT209255">Apple</a> and
  <a href="https://github.com/chromium/ct-policy/blob/master/ct_policy.md"
    >Google</a
  >
  CT programs.
</li>
<li>Our production ACME API environment submits certificates here.</li>
{{< /ct_logs >}} {{< ct_logs data="testing" >}}
<li>
  SCTs from these logs <b>SHOULD NOT</b> be incorporated into publicly trusted
  certificates.
</li>
<li>
  The Let's Encrypt production and
  <a href="/docs/staging-environment">staging</a> ACME API environments both
  submit certificates to Sapling, but the production environment does not use
  the resulting SCTs.
</li>
<li>
  We test new versions of
  <a href="http://github.com/google/trillian">Trillian</a> and
  <a href="https://github.com/google/certificate-transparency-go"
    >certificate-transparency-go</a
  >
  here before deploying them to production.
</li>
<li>
  Sapling's accepted roots list includes all of the Oak accepted roots, plus
  additional test roots.
</li>
<li>
  Sapling can be used by other certificate authorities for testing purposes.
</li>
{{< /ct_logs >}}

<h2>Log Operations</h2>
<p>
  To enumerate the included roots for a particular CT log, you can run the
  following command in the terminal of your choice:
</p>
<pre>
$ for i in $(curl -s https://oak.ct.letsencrypt.org/2020/ct/v1/get-roots | jq -r '.certificates[]'); do
    echo '------'; base64 -d &lt;&lt;&lt; "${i}" | openssl x509 -inform der -noout -issuer -serial
done
</pre>

<p>
  Submitting certificates to a CT log is typically handled by certificate
  authorities. If you'd like to experiment with this, begin by retrieving an
  arbitrary PEM encoded certificate from our favorite website. Copy and paste
  the following block into your terminal.
</p>
<pre>
$ echo | \
openssl s_client \
    -connect "letsencrypt.org":443 \
    -servername "letsencrypt.org" \
    -verify_hostname "letsencrypt.org" 2&gt;/dev/null | \
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' &gt; example.crt
</pre>

<p>
  Before a certificate can be submitted, it must be JSON encoded within a
  special structure. You can use the JSON generator provided by
  <a href="https://crt.sh/gen-add-chain">https://crt.sh/gen-add-chain</a> to
  perform this task. The crt.sh utility will return a JSON bundle. Download the
  bundle to your computer, rename the file if you must, and issue the following
  command to perform the add-chain operation (<a
    href="https://tools.ietf.org/html/rfc6962#section-4.1"
    >RFC 6962 section 4.1</a
  >) to submit the certificate to a CT log. The output will contain a signature
  which is in fact an
  <a href="https://letsencrypt.org/2018/04/04/sct-encoding.html">SCT</a>. More
  on the signature in a moment.
</p>
<pre>
$ curl \
    -X POST \
   --data @example-json-bundle.json \
    -H "Content-Type: application/json" \
    -H "User-Agent: lets-encrypt-ct-log-example-1.0" \
   https://oak.ct.letsencrypt.org/2020/ct/v1/add-chain
{"sct_version":0,"id":"5xLysDd+GmL7jskMYYTx6ns3y1YdESZb8+DzS/JBVG4=","timestamp":1576689972016,"extensions":"","signature":"BAMARzBFAiEA4OmuTcft9Jq3XLtcdZz9XinXCvYEY1RdSQICXayMJ+0CIHuujkKBLmQz5Cl/VG6C354cP9gxW0dfgMWB+A2yHi+E"}
</pre>

<p>
  To confirm that the CT log was signed by the Oak 2020 shard, we use the id
  field from the command above and run it through the following command. The
  result of this will output the Log ID of the CT log.
</p>
<pre>
$ base64 -d &lt;&lt;&lt; "5xLysDd+GmL7jskMYYTx6ns3y1YdESZb8+DzS/JBVG4=" | xxd -p -c 64 | sed -e 's/../&:/g' -e 's/:$//' | tr '[:lower:]' '[:upper:]'
E7:12:F2:B0:37:7E:1A:62:FB:8E:C9:0C:61:84:F1:EA:7B:37:CB:56:1D:11:26:5B:F3:E0:F3:4B:F2:41:54:6E
</pre>

<p>
  Using the signature field, we can verify that the certificate was submitted to
  a log. Using our
  <a href="https://letsencrypt.org/2018/04/04/sct-encoding.html"
    >SCT deep dive guide</a
  >, you could further decode this value.
</p>
<pre>
$ base64 -d &lt;&lt;&lt; "BAMARzBFAiEA4OmuTcft9Jq3XLtcdZz9XinXCvYEY1RdSQICXayMJ+0CIHuujkKBLmQz5Cl/VG6C354cP9gxW0dfgMWB+A2yHi+E" | xxd -p -c 16 | sed -e 's/../&:/g' -e 's/:$//' | tr '[:lower:]' '[:upper:]'
04:03:00:47:30:45:02:21:00:E0:E9:AE:4D:C7:ED:F4
9A:B7:5C:BB:5C:75:9C:FD:5E:29:D7:0A:F6:04:63:54
5D:49:02:02:5D:AC:8C:27:ED:02:20:7B:AE:8E:42:81
2E:64:33:E4:29:7F:54:6E:82:DF:9E:1C:3F:D8:31:5B
47:5F:80:C5:81:F8:0D:B2:1E:2F:84
</pre>
